Updating cookies in header during request processing

--0015175cd0ea5bbb000473d9ea8a
Content-Type: text/plain; charset=ISO-8859-1

I was very excited by the suggestion to use cookies to store the entire
session information, and to keep it safe by means of base64 encoding and MD5
hash with a secret salt, for storing session information securely on the
client.

I realized that there is something I am missing. Sometimes I may need to put
something into the session after I did $cgi->start_html. I can do it if the
cookie is only a session ID, with session data stored in mysql.

But how can I change the cookie AFTER I called $cgi->start_html?

If I can do that, I think that I am set to go.

thanks

Igor

--0015175cd0ea5bbb000473d9ea8a
Content-Type: text/html; charset=ISO-8859-1

I was very excited by the suggestion to use cookies to store the entire session information, and to keep it safe by means of base64 encoding and MD5 hash with a secret salt, for storing session information securely on the client.


I realized that there is something I am missing. Sometimes I may need to put something into the session after I did $cgi->start_html. I can do it if the cookie is only a session ID, with session data stored in mysql.


But how can I change the cookie AFTER I called $cgi->start_html?

If I can do that, I think that I am set to go.

thanks

Igor


--0015175cd0ea5bbb000473d9ea8a--

Re: Updating cookies in header during request processing

On 09/18/2009 09:14 AM, Igor Chudov wrote:

> I realized that there is something I am missing. Sometimes I may need to
> put something into the session after I did $cgi->start_html. I can do it
> if the cookie is only a session ID, with session data stored in mysql.

This might be a larger architectural problem them. IMO, you really
shouldn't use CGI.pm for HTML generation. Most people use a template of
some sort for that.

And the next thing would be to reorganize your code so that you aren't
tied to a specific order of doing things. For instance, I normally use
CGI::Application which lets me do all kinds of things to the headers and
content until I'm all ready to return at the end of my run mode. The
order doesn't matter.

> But how can I change the cookie AFTER I called $cgi->start_html?

Since cookies are part of the HTTP headers they need to go out before
any HTML content. So instead of just printing the content as you go, why
don't you collect your HTML into a variable and then print it all out at
the end.

--
Michael Peters
Plus Three, LP

Re: Updating cookies in header during request processing

On Fri 18 Sep 2009, Igor Chudov wrote:
> But how can I change the cookie AFTER I called $cgi->start_html?

As long as there is nothing sent out on the wire you can add headers.
When the response header is gone you can't. start_html() only generates
a string as far as know. So it depends upon when this string is sent.

But with mod_perl you can circumvent even this limitation. Write a
caching output filter.

Torsten

--
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net

Re: Updating cookies in header during request processing

>>>>> "Igor" == Igor Chudov writes:

Igor> I was very excited by the suggestion to use cookies to store the entire
Igor> session information, and to keep it safe by means of base64 encoding and
Igor> MD5 hash with a secret salt, for storing session information securely on
Igor> the client.

Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that
cookies should really just be used to distinguish one browser from another,
and hold everything server-side instead for far better security and
flexibility. (Remember, server-side could be something as simple as
DBM::Deep, which is a single-file zero-install module that gives you
arbitrary persistent Perl data structures efficiently.)

See my (slightly aged but still valid) write-up of this at:

http://www.stonehenge.com/merlyn/WebTechniques/col61.html

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Updating cookies in header during request processing

On 09/18/2009 10:33 AM, Randal L. Schwartz wrote:

> Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that
> cookies should really just be used to distinguish one browser from another,
> and hold everything server-side instead for far better security and
> flexibility.

I disagree. Using cookies for session data has a lot of advantages:

+ No need to have a permanent data store (DBD::Deep is single server
only and why waste the resources to go across the network to your DB or
cache if you don't have to). Also no need to clean up this data store
periodically. Having a single source for this data also kills scalability.

+ If it's commonly used data, putting it into a cookie will make it
available to the client side Javascript. Why waste server resources to
do what the client's machine can do. In fact, I find it's more flexible
to have this information in the cookie since my front end folks can then
use it to add functionality without having to trouble the back end folks.

And securing a cookie is pretty easy. If the information is not
sensitive then you just need to put a hash in it to make sure it's not
tampered with. If it is sensitive, then encryption works for cookies
too. I'm not saying there aren't uses for large server side sessions,
but I think they are pretty few.

--
Michael Peters
Plus Three, LP

Re: Updating cookies in header during request processing

>>>>> "Michael" == Michael Peters writes:

Michael> On 09/18/2009 10:33 AM, Randal L. Schwartz wrote:
>> Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that
>> cookies should really just be used to distinguish one browser from another,
>> and hold everything server-side instead for far better security and
>> flexibility.

Michael> I disagree. Using cookies for session data has a lot of advantages:

[justifications snipped]

Yes. Welcome to phase 2. Eventually, you'll enter phase 3. The smarter
webdev people always do. I sounded exactly like you, once, and then grew out
of it. The more you resist, the longer your delay. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Updating cookies in header during request processing

All due respect, but hat's a little condescending... I generally cringe
when I hear anyone advocating that there is one "right" way to do things
that should be used in every instance

In addition to Michael's points (which are totally valid) I would add
that your solution is great for small/medium sized sites but as soon as
you scale into sites with very large amounts of traffic it quickly
raises a lot of operational concerns about where to store that data in
place that's retrievable in a short enough time frame to not degrade
performance. Solving that problem is going to cost time and money and
will sometimes result in your application caring about session affinity,
which is another operational concern.

I'm not saying that these problems aren't solvable, I'm simply saying
that I don't think it's nearly as cut and dried as you seem to,
especially when you look at the app from and operational perspective.

I can see both sides of this argument and I can see situations in in
which either solution might be advantageous over the other. A lot
depends on budget, environmental layout, how often the session is
updated, how much data you're storing, etc... Perhaps you could outline
in a little more detail why you think storing everything server side is
the only "right" way to do things?
>
>
>
> Randal L. Schwartz wrote:
>>>>>>> "Michael" == Michael Peters writes:
>>>>>>>
>>
>> Michael> On 09/18/2009 10:33 AM, Randal L. Schwartz wrote:
>>
>>>> Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that
>>>> cookies should really just be used to distinguish one browser from another,
>>>> and hold everything server-side instead for far better security and
>>>> flexibility.
>>>>
>>
>> Michael> I disagree. Using cookies for session data has a lot of advantages:
>>
>> [justifications snipped]
>>
>> Yes. Welcome to phase 2. Eventually, you'll enter phase 3. The smarter
>> webdev people always do. I sounded exactly like you, once, and then grew out
>> of it. The more you resist, the longer your delay. :)
>>
>>

Re: Updating cookies in header during request processing

On 09/18/2009 11:15 AM, James Smith wrote:

> But cookies are in general not big enough to store the information that
> a user would store on a website!

I'm not talking about eliminating a permanent data store for your users.
I'm talking about replacing the session specific things. How much
session specific data do you really need to store? If it's bigger than
4K per-user than yes you can't use a single cookie. But like I said
before, the situations that you really need more than that for *session
specific* data are pretty rare.

> and security is not just on your server
> (but also on the clients machine) so if the browser can read it - anyone
> that can compromise the browser can also read it - if it is on the
> server that is harder!

It's almost as if people aren't reading my other emails :) If you need
to prevent tampering, use a hash. If you need to completely secure the
data, encrypt it.

--
Michael Peters
Plus Three, LP

Re: Updating cookies in header during request processing

On 09/18/2009 11:19 AM, Randal L. Schwartz wrote:

> Yes. Welcome to phase 2. Eventually, you'll enter phase 3.

I used to be a phase 3 convert and then some really smart people
convinced me otherwise :)

--
Michael Peters
Plus Three, LP

Re: Updating cookies in header during request processing

--000325555d267c9e640473dcb152
Content-Type: text/plain; charset=ISO-8859-1

Hi Randal, nice to see you. Your suggestion is where I am coming FROM: right
now the cookie is only a key into the mysql table which holds session data.

What I want is to stop using that table altogether and let the browser hold
the information, in a manner that is straightforward, flexible and secure.

Igor

On Fri, Sep 18, 2009 at 9:33 AM, Randal L. Schwartz
wrote:

> >>>>> "Igor" == Igor Chudov writes:
>
> Igor> I was very excited by the suggestion to use cookies to store the
> entire
> Igor> session information, and to keep it safe by means of base64 encoding
> and
> Igor> MD5 hash with a secret salt, for storing session information securely
> on
> Igor> the client.
>
> Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize
> that
> cookies should really just be used to distinguish one browser from another,
> and hold everything server-side instead for far better security and
> flexibility. (Remember, server-side could be something as simple as
> DBM::Deep, which is a single-file zero-install module that gives you
> arbitrary persistent Perl data structures efficiently.)
>
> See my (slightly aged but still valid) write-up of this at:
>
> http://www.stonehenge.com/merlyn/WebTechniques/col61.html
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside
> discussion
>

--000325555d267c9e640473dcb152
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Randal, nice to see you. Your suggestion is where I am coming FROM: righ=
t now the cookie is only a key into the mysql table which holds session dat=
a.

What I want=A0 is to stop using that table altogether and let th=
e browser hold the information, in a manner that is straightforward, flexib=
le and secure.


Igor

Re: Updating cookies in header during request processing

--0015175cffac8a6a8e0473dcf8fa
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 18, 2009 at 10:51 AM, Michael Peters wrote:

> On 09/18/2009 11:15 AM, James Smith wrote:
>
> But cookies are in general not big enough to store the information that
>> a user would store on a website!
>>
>
> I'm not talking about eliminating a permanent data store for your users.
> I'm talking about replacing the session specific things. How much session
> specific data do you really need to store? If it's bigger than 4K per-user
> than yes you can't use a single cookie. But like I said before, the
> situations that you really need more than that for *session specific* data
> are pretty rare.
>

In my case, in almost all instances, the only thing I would want to store is
authenticated userid. But I cannot exclude other possibilities. Right now I
use Apache::Session to store a hash in a mysql table "sessions".

I have a "users" table that holds their profile information such as their
email, their picture, etc.

If I can find a way to set that cookie after the request is processed, I
would be very happy. I can _probably_ work around it and set cookie before
doing start_html, but I would prefer not to.

Regarding another comment on using templates, etc: I have basically a
homegrown CMS on algebra.com. And I do support templates: the presentation
is mostly decoupled from content, such as where ads are places, how
navigation aids are presented etc, is all decoupled. I can work on the new
template for a month and the users will not notice as they will see the old
template. But I like what I have as it is my own.


Igor

--0015175cffac8a6a8e0473dcf8fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Re: Updating cookies in header during request processing

>>>>> "Igor" == Igor Chudov writes:

Igor> In my case, in almost all instances, the only thing I would want to
Igor> store is authenticated userid.

The problem with that is public web browsers. You *cannot* ensure the
expiration of an auth cookie, so you'll have to have some sort of server-side
data to say "this user most recently authenticated at this time, so I still
trust him".

And once you've done that, why store *any* auth client side? Just brand the
browser, as my article says.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Updating cookies in header during request processing

On 09/18/2009 12:57 PM, Randal L. Schwartz wrote:

> The problem with that is public web browsers. You *cannot* ensure the
> expiration of an auth cookie, so you'll have to have some sort of server-side
> data to say "this user most recently authenticated at this time, so I still
> trust him".

Why does this have to be server side? Why can't it be part of the
cookie's (tamper proof) data itself?

--
Michael Peters
Plus Three, LP